(passes the whole official test suite, except for the two tests that require big nums to be treated as integers, which is not feasible in PHP)

I'm a bit out of PHP land now, but have you looked at BCMath?
It would be good to at least link to an issue which has further information on which tests are failing and why.

Regardless, I'll accept.

@Relequestual, thanks for the merge. I did look at BCMath but it won't help in this case. The fact is PHP doesn't know big nums. If one of these is encountered when parsing json data using the standard json_decode function, it will be either converted to float (default behaviour) or to string (if that option is specified). Either way, from this point you have no mean to identify what was the original json data type, so tests like "a bignum is an integer", "a bignum is not a string", etc. are doomed to fail.

I guess if big num support was an absolute requirement, you could build your own json_decode implementation, which would wrap primitive numeric types and reimplement every needed function dealing with them but IMO it would result in something far too exotic to be broadly useful in the PHP landscape.

PS: I see one PHP validator passing the whole test suite, but it relies on a string conversion trick that make its behaviour incorrect in some cases.

Interesting! Makes it behave incorrectly in some cases? Any idea which cases? (Because those should be added to the test suite... right?)

At least it tries to do the right thing

Maybe you could warn, and allow the application to handle those intsnaces. Throwing thoughts at the wall on this one.
Also related http://stackoverflow.com/a/37095777/89211

I'm annoyed / dissapointed at this problem (of json-schema), give how much flak I give swagger for similar validation issues. =/

@awwright Any thoughts on this? (not the PR, but the discussion)

Makes it behave incorrectly in some cases? Any idea which cases? (Because those should be added to the test suite... right?)

I agree. If I'm not mistaken, the implementation mentionned above will report that instance:

"12345678910111213141516171819202122232425262728293031"

valid against that schema:

{ "type": "integer" }

instead of reporting a type mismatch error (string vs expected integer).

At least it tries to do the right thing

It's not like I didn't try to do something about it. I just think we hit a PHP limitation here. I thought that the optional folder was for cases like this one.

It's even more tricky in perl land =D

@stefk @Relequestual Technically, JSON Schema describes application/json documents, the string of bytes before it gets parsed into any data structure.

If the JSON Schema library is itself using json_decode, you just have to be aware of those limitations, that you're not actually validating the application/json document, but a copy that might have been modified from the original.

Virtually everyone tests against an in-memory structure, though. It's not that big of an issue, as long as the result would be the same as json_encoding and testing this (modified) copy.

Having slept on this discussion, I consider that, if a languge handles some JSON structure in one way when decoding, and that's the standard way, then I feel that's fine. A library will validate the sturcture as far as the language in use understands it.

I see your point about validation before it gets parsed, but that sort of also doesn't make sense. I mean, you HAVE to parse the JSON in order to read it, at all.

Thank you both for your input! I think we all agree that pragmatism is needed on that issue, and that fighting the language default tooling and data structures isn't probably worth it ;)

It's a tricky one for sure. I had some similar instances with Perl. I won in the end ;)
I think what I was trying to say is, if the language doesn't know the difference between A and B, then it's mostly fruitless to try and validate A vs B also.